home *** CD-ROM | disk | FTP | other *** search
- From: kanze@gabi.gabi-soft.fr (J. Kanze)
- Message-ID: <KANZE.96Jan22120854@gabi.gabi-soft.fr>
- X-Original-Date: 22 Jan 1996 11:08:54 GMT
- Path: in1.uu.net!bounce-back
- Date: 22 Jan 96 13:38:45 GMT
- Approved: fjh@cs.mu.oz.au
- Newsgroups: comp.std.c++
- Subject: Re: STL still in standard
- Organization: GABI Software, Sarl.
- References: <4dd7on$djk@rc1.vub.ac.be> <4dgrb4$a2e@engnews1.Eng.Sun.COM>
- <9601171106.AA12639@lts.sel.alcatel.de> <4du1v6$h74@jupiter.SJSU.EDU>
- In-Reply-To: horstman@jupiter.SJSU.EDU's message of 21 Jan 96 23:03:54 GMT
- X-Auth: PGPMoose V1.1 PGP comp.std.c++
- iQBFAgUBMQOTpuEDnX0m9pzZAQESVwGAie57k0NkQGFf1ekiyMxkdYyr4xFBGqUP
- b1XlP/yXYDRXUZxcu2gtTr+y4JY6hjdj
- =dZlO
-
- In article <4du1v6$h74@jupiter.SJSU.EDU> horstman@jupiter.SJSU.EDU (Cay
- S. Horstmann) writes:
-
- > James Kanze US/ESC 60/3/141 #40763 <kanze@lts.sel.alcatel.de> wrote:
- >
- > >Safer implementations are possible; Cay Horstman, I think, has already
- > >made one available.
- >
- > Indeed. It works nicely as a debugging tool, and is 100% compatible
- > with plain STL. Think of it as an "assert" for STL. It is available
- > from http://www.mathcs.sjsu.edu/faculty/horstman/safestl.html. A
- > number of people at NYU have ported it to g++. If there is interest,
- > I'll find out how far they got.
-
- Is it just for debugging. I would imagine that one would be using this
- version most of the time, in preference to something more dangerous, and
- only abandon it when profiling showed that it was necessary.
-
- > >Exception safe implementations are also possible.
- > >(It is also an open question how far one wants to go here. I would
- > >accept, for example, that an exception from the comparison function
- > >when inserting into a map results in undefined behavior; if comparison
- > >can throw an exception, an STL map is perhaps not the appropriate
- > >container.)
- >
- > I am not sure exceptions are the way to go--the great value of a
- > standard is that it is, well, standard. STL may not be the greatest
- > library on the planet, but it is certainly good enough, and it is
- > standard. I don't like the idea of tinkering with the interface by
- > adding exceptions.
-
- Exceptions cannot be avoided. If the behavior of STL is declared
- undefined if an object of the instantiation type throws an exception,
- for example, then it becomes practically unusable. Most of my objects
- will acquire dynamic memory, and operator new may throw an exception.
-
- This is not tinkering with the interface, this is a standards question:
- what is the defined behavior of, e.g.: vector< T > if T throws an
- exception? What is the state of
-
- vector< T > v( 5 ) ;
-
- if the third call to T::T( T const& ) (to initialize v[ 2 ]) causes an
- exception to be thrown.
-
- In the current (HP) implementation, v[ 0 ] and v[ 1 ] will have been
- fully constructed; v[ 2 ] presumably will have coped correctly to appear
- unconstructed, and v[ 3 ] and v[ 4 ] are just chunks of raw memory.
-
- IMHO, for example, in the above case, it should be explicitly stated
- that the entire array is just raw memory. (Note that because the
- exception propagates up out of the constructor of vector< T >, before
- the constructor has finished, the corresponding destructor will not be
- called.) The user has *no* way of doing proper clean-up.
-
- > My model here is the C string.h library. Consider strncpy. Could you
- > imagine a dumber function? If either of the arguments is null, it
- > dumps core. 99% of strncpy uses in my programs are of the form
- > strncpy(buffer, s, sizeof(buffer));
- > buffer[sizeof(buffer) - 1] = 0;
- > Sure, in 1% of the cases, I am glad it doesn't add the terminating 0,
- > but in 99% of the cases I hate it. But did I go out and write my own
- > superior replacement of strncpy? I did for a while and all of my team
- > members protested. They didn't want to learn my pet library. So I am
- > back to strncpy. Like Bjarne Stroustrup wrote, library design is
- > language design.
- >
- > Same with STL. I'd rather not figure out subtle differences between
- > customized STL versions, especially with something as subtle as
- > exception specifications. If it is a good idea for STL to throw
- > exceptions when the user inserts something stupid, then let's lobby to
- > make that a part of the standard. Otherwise put the test in the user
- > code, not into a custom STL.
-
- I agree. The present situation is that there is one aspect of the
- interface definition which has not been defined. In order to be useful,
- it must be.
- --
- James Kanze (+33) 88 14 49 00 email: kanze@gabi-soft.fr
- GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
- Conseils, itudes et rialisations en logiciel orienti objet --
- -- A la recherche d'une activiti dans une region francophone
- ---
- [ comp.std.c++ is moderated. Submission address: std-c++@ncar.ucar.edu.
- Contact address: std-c++-request@ncar.ucar.edu. The moderation policy
- is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]
-